1.1.2 AI 기반 소프트웨어 개발(Software 2.0)의 부상: 데이터와 확률적 모델링

1. 컴퓨팅 패러다임의 거대한 변곡점: Software 2.0의 도래

현대 소프트웨어 엔지니어링 생태계는 근본적인 변곡점을 통과하고 있다. 1950년대 메인프레임 컴퓨팅의 여명기부터 최근의 모바일 및 클라우드 컴퓨팅 플랫폼의 전환기에 이르기까지, 약 70여 년간 컴퓨팅 스택의 핵심은 변함없이 인간이 작성한 명시적인 지시어 기반의 시스템에 머물러 있었다. 개발자가 문제의 논리적 해결책을 기하학적, 수학적으로 분해하여 알고리즘을 고안하고, 이를 컴퓨터가 이해할 수 있는 프로그래밍 언어의 명령어로 치환하는 방식은 소프트웨어 개발의 절대적인 불문율로 여겨졌다. 그러나 딥러닝 기술의 폭발적인 발전과 대규모 신경망 아키텍처의 상용화는 이러한 전통적인 엔지니어링의 근본 전제를 송두리째 뒤흔들고 있다.

이러한 거대한 패러다임의 전환을 가장 명확하게 정의한 것은 전 테슬라(Tesla) AI 디렉터이자 인공지능 연구자인 안드레이 카파시(Andrej Karpathy)가 2017년에 주창한 ’Software 2.0’이라는 개념이다. 카파시는 자신의 선구적인 분석을 통해 신경망이 단순한 통계적 예측 도구를 넘어, 소프트웨어 자체를 개발하는 새로운 형태의 ’메타 소프트웨어(Meta-software)’로 진화하고 있음을 역설했다. 그에 따르면, 전통적인 소프트웨어 개발인 Software 1.0은 인간 개발자가 시스템이 직면할 모든 상황에 대해 수천, 수만 줄의 명시적 코드를 작성하여 컴퓨터의 동작을 꼼꼼하게 제어하는 ‘결정론적(Deterministic)’ 소프트웨어이다. 반면, Software 2.0은 인간이 직접 소스 코드를 작성하는 대신, 목적 함수(Objective Function)와 최적화(Optimization) 알고리즘, 즉 신경망 훈련 과정을 통해 ‘스스로 코드를 작성하는’ 패러다임을 의미한다.

이러한 전환이 일어난 핵심적인 이유는 현실 세계의 복잡한 문제들이 지니는 본질적인 속성 때문이다. 컴퓨터 비전, 자연어 번역, 음성 인식과 같은 영역의 문제들은 개발자가 명시적인 프로그램 규칙을 작성하여 해결하는 것보다, 이상적인 동작을 식별하고 이를 나타내는 대규모 데이터셋을 수집하는 것이 압도적으로 쉽고 효율적이다. 예를 들어, 이미지 내의 객체를 분류하는 작업을 수행할 때, 전통적인 기하학적 분석이나 규칙 기반의 프로그래밍으로 모든 시각적 변형과 조도 변화를 처리하는 것은 사실상 불가능에 가깝다. 반면 Software 2.0 스택에서는 대규모 연산 그래프(Computational Graphs) 위에서 종단간(End-to-End) 학습이 가능한 신경망을 통해, 데이터 속에 숨겨진 패턴과 상관관계를 알고리즘이 스스로 찾아내어 문제를 해결한다. 이는 소프트웨어 개발 방식이 ’명령적 프로그래밍(Imperative Programming)’에서 목표와 예제를 제시하면 프로그램이 스스로 목적지에 도달하는 ’예제에 의한 프로그래밍(Programming by Example)’으로 완전히 대체되었음을 의미한다.

2. 코드에서 데이터로: 엔지니어링 자원의 중심 이동과 역할의 분화

Software 2.0 패러다임은 단순히 코드를 작성하는 도구의 변화를 넘어, 소프트웨어 개발 팀의 구조와 개발자의 역할, 그리고 시스템의 핵심 가치 창출 지점을 완전히 이동시켰다. 이 새로운 환경에서 데이터는 과거 Software 1.0 시대의 소스 코드와 완벽하게 동일한, 혹은 그 이상의 지위를 획득하게 된다.

2.1 개발 조직의 양분화와 데이터 큐레이션의 부상

Software 2.0은 소프트웨어 엔지니어링 팀을 두 개의 명확한 축으로 양분한다. 카파시의 예측에 따르면, 미래의 2.0 프로그래머들은 더 이상 복잡한 로직을 구현하는 코드를 작성하지 않는다. 그들은 방대하고 다양한 데이터셋을 수동으로 큐레이션(Curation)하고, 병합하며, 정제하고, 레이블을 지정하는 작업에 전념한다. 시스템의 최종적인 동작과 성능은 이들이 큐레이션한 데이터셋에 의해 간접적이지만 결정적으로 지시된다. 이와 병행하여 1.0 프로그래머들은 이러한 2.0 생태계가 원활하게 작동할 수 있도록 지원하는 인프라스트럭처에 집중한다. 이들은 주변 도구, 분석 및 시각화 시스템, 레이블링 인터페이스, 그리고 모델을 훈련시키는 핵심 코드를 유지보수하는 역할을 맡게 되며, 이는 전체 시스템이 자율적으로 진화할 수 있는 토대를 제공한다.

이러한 전환은 스탠포드 대학의 Hazy Research 연구소에서 개발한 약지도학습(Weak Supervision) 시스템인 Snorkel의 진화 과정에서도 명확히 드러난다. 연구진은 모델 아키텍처 자체가 점차 상품화(Commoditize)될 것임을 예측하고, 머신러닝 시스템 구축의 진정한 병목 현상이 ’훈련 데이터의 확보’에 있음을 깨달았다. 엔지니어들이 모델의 내부 구조를 튜닝하는 대신 ’모델에 무엇을 넣을 것인가’에 시간을 집중하게 되는 현상은, 프로그램의 동작을 코드가 아닌 훈련 예제를 통해 지정하는 Software 2.0의 본질을 완벽하게 보여준다. 이를 통해 머신러닝 시스템 성능을 좌우하는 중심축이 알고리즘 설계에서 데이터 엔지니어링으로 완전히 이동했음이 증명되었다.

2.2 소스 코드 디버깅에서 데이터 디버깅으로

데이터가 소프트웨어의 동작을 정의하는 제1급 객체(First-class citizen)로 격상됨에 따라, 품질 보증 및 유지보수의 패러다임 역시 데이터 중심적으로 재편되어야 한다. 전통적인 Software 1.0에서는 인간이 작성한 코드의 논리적 결함을 찾아 수정하는 디버깅(Debugging)이 필수적이었다. 인간이 작성한 디버깅되지 않은 코드를 운영 환경에서 신뢰할 수 없는 것처럼, 머신러닝 모델의 가중치를 결정하는 데이터 역시 철저한 디버깅 과정을 거쳐야 한다.

Software 2.0 시스템에서는 모델 파이프라인 전반에 걸쳐 데이터와 레이블에 내재된 오류, 노이즈, 편향(Bias)이 침투할 수 있으며, 이러한 데이터 버그를 체계적으로 식별하고 제거하는 작업이 소프트웨어 공학의 새로운 핵심 역량으로 떠오르고 있다. 구글의 What-If Tool과 같은 대화형 시각적 인터페이스의 등장은 사용자가 방대한 코드 없이도 데이터의 편향성과 머신러닝 모델의 동작을 분석하고 디버깅할 수 있도록 돕는 대표적인 발전 사례이다.

2.3 시스템 핵심 컴포넌트의 기계 학습화

데이터 기반의 확률적 모델링은 애플리케이션 계층을 넘어 데이터 관리 시스템의 가장 깊숙한 핵심 인프라까지 침투하고 있다. 이를 가장 혁신적으로 보여주는 연구가 논문 The Case for Learned Index Structures이다. 이 연구는 데이터베이스 시스템의 근간을 이루는 B-Tree, Hash, Bloom 필터와 같은 전통적인 데이터 구조를 하나의 ’모델’로 재해석했다. B-Tree 인덱스가 키(Key)를 정렬된 배열 내의 레코드 위치로 매핑하는 결정론적 모델이라면, 이를 데이터의 누적 분포 함수(CDF)를 학습한 신경망으로 대체할 수 있다는 것이다. 이 연구는 핵심 시스템 컴포넌트를 학습된 모델로 대체함으로써 메모리 사용량을 줄이고 검색 속도를 비약적으로 향상시킬 수 있음을 입증했으며, 향후 컴퓨팅 시스템 설계 전반이 명시적 로직에서 학습 기반 구조로 전환될 것임을 강력하게 시사한다.

3. 결정론적 로직에서 확률적 모델링으로의 수학적 전환

Software 1.0에서 Software 2.0으로의 근본적인 도약은 소프트웨어 시스템의 입출력 관계가 수학적으로 완전히 다른 기반 위에 구축됨을 의미한다. 과거의 소프트웨어가 이산 수학과 결정론적 논리에 지배받았다면, 새로운 소프트웨어는 연속적인 확률 공간과 통계적 추론에 의해 구동된다.

3.1 조건부 확률과 모델 네트워크의 구축

전통적인 소프트웨어의 동작은 입력 x에 대해 언제나 유일하고 확정적인 출력 y를 반환하는 결정론적 함수 y = f(x)로 모델링된다. 동일한 입력이 주어지면 프로세서의 상태는 언제나 예측 가능한 동일한 경로를 따라 실행되며 100% 동일한 출력을 보장한다. 반면, 기계 학습과 Software 2.0은 연속적인 확률 분포에 기반하여, 입력 특징 x가 주어졌을 때 출력 y가 나타날 조건부 확률 분포 P(y \vert x)를 직접 학습하는 과정을 거친다.

머신러닝에서의 확률적 모델링은 주변 분포(Marginal distribution) P(X_i), 모든 변수로 설명되는 결합 분포(Joint distribution) P(X_1, \dots, X_n), 그리고 추가 정보가 주어졌을 때의 조건부 분포(Conditional distribution) P(X \vert Y)를 아우른다. 복잡한 스칼라 출력이나 다차원 데이터를 처리할 때, 일반화된 선형 모델과 같은 모수적(Parametric) 가정은 한계가 명확하므로 유연한 비모수적(Non-parametric) 모델이나 신경망을 통해 y의 조건부 누적 분포 함수를 직접 학습함으로써 더 정밀한 확률적 추정치를 도출하게 된다. 코드 요소가 확률적 모델 네트워크의 노드로 변환되고, 이를 통해 모델 변수와 근사치(Approximating quantity)를 기술하는 확률적 표현식이 구축되는 과정은 시스템의 추론 과정을 근본적으로 변화시킨다.

3.2 생성형 AI와 대규모 언어 모델의 확률적 본질

이러한 확률적 특성이 가장 극단적으로 발현되는 시스템이 바로 대규모 언어 모델(LLM)이다. LLM은 본질적으로 구조화된 프롬프트 시퀀스를 받아 다단계의 추론 과정을 거쳐 방대한 어휘(Vocabulary) 집합에 대한 확률 분포를 생성하는 ’자가회귀적(Autoregressive) 다음 토큰 예측 엔진’이다. 토큰화 과정을 통해 텍스트를 식별자로 변환하고, 임베딩과 위치 인코딩을 거친 후, 수많은 트랜스포머 블록의 어텐션(Attention) 및 피드포워드(Feed-forward) 네트워크를 통과하며 은닉 상태(Hidden states)를 정제한다. 이후 판독 계층(Readout layer)에서 로짓(Logits)을 생성하고, 최종적으로 소프트맥스(Softmax) 정규화를 거쳐 다음 토큰의 확률 분포를 출력하게 된다.

이 모델의 수학적 거동은 확률론적 표현식으로 명확히 정의된다. 주어진 입력 시퀀스 s에 대해 다음 토큰 t가 생성될 확률 p_{\theta}(t \vert s)는 다음과 같은 수학적 형태를 띤다.

p_{\theta}(t \vert s) = \frac{\exp(z_{t}/T)}{\sum_{t^{\prime} \in \mathcal{V}} \exp(z_{t^{\prime}}/T)}

여기서 \mathcal{V}는 전체 어휘의 집합이며, z_t는 해당 토큰의 로짓, T > 0는 분포의 첨도(Sharpness)를 제어하는 온도(Temperature) 파라미터이다. 디코딩 전략 시 탐욕적 탐색(Greedy search), Top-k, Top-p 등 다양한 기법이 적용되지만, 근본적으로 LLM의 동작은 이 확률 분포 위에서 무작위로 표본을 추출하는 샘플링 과정에 지나지 않는다. 모델이 마치 논리적으로 추론(Reasoning)하거나 도구를 사용하는 것처럼 보이는 고차원적 행위조차도, 구조화된 프롬프트 위에서 이 기본적인 자가회귀 확률 예측 메커니즘이 반복적으로 재사용된 결과물에 불과하다.

또한 최신 LLM 성능 고도화의 핵심인 인간 피드백 기반 강화학습(RLHF)이나 직접 선호도 최적화(DPO, Direct Preference Optimization) 기법 역시 이 확률적 토대 위에서 이루어진다. DPO는 별도의 보상 모델을 학습하는 대신, Bradley-Terry 선호도 모델을 암묵적으로 가정하여 인간의 선호 데이터를 정책 \pi_\theta에 직접 최적화한다. 입력 x가 주어졌을 때 더 선호되는 응답 y_w가 덜 선호되는 응답 y_l보다 선택될 확률은 다음과 같이 수식화된다.

p(y_w \succ y_l \vert x) = \sigma\left(\beta \log \frac{\pi_\theta(y_w \vert x)}{\pi_{\text{ref}}(y_w \vert x)}\right)

이 수식은 개발자의 ’명시적 의도’나 ’절대적인 정답’조차도, 실제로는 확률 모델 간의 로그 우도(Log-likelihood) 비율 차이에 기반한 시그모이드(Sigmoid) 함수값으로 수학적으로 계량화되고 근사화됨을 보여준다. 즉, 완벽한 정답이 존재하는 것이 아니라 ’더 나은 확률적 선호도’만이 존재할 뿐이다.

3.3 과적합(Overparameterization)과 확률적 추론의 융합

신경망이 이처럼 방대한 확률 공간을 성공적으로 매핑할 수 있는 원동력은 파라미터의 수가 훈련 데이터의 크기를 아득히 초과하는 ‘과적합(Overparameterization)’ 현상에 있다. 흥미롭게도 최근의 학술적 조망에 따르면, 과적합은 단순히 머신러닝 영역에만 국한된 현상이 아니다. Software 1.0 시스템 역시 작업에 필요한 최소한의 연산보다 훨씬 더 방대하고 복잡한 추상화 계층을 거치며 본질적으로 과적합된 상태로 구동된다는 것이다.

확률적 프로그래밍(Probabilistic Programming) 관점에서 소프트웨어 시스템의 거동은 확률적 선택(Stochastic choices)을 포함하는 프로그램으로 구조화될 수 있다. 이러한 통합적 관점하에 프로그래밍 시스템은 “이 프로그램이 주어진 임계값을 초과하는 값을 반환할 확률은 얼마인가?“와 같은 고차원적인 질문에 대한 해답을 탐색하기 위해 방대한 추론 알고리즘 공간을 탐색한다. 이는 Software 1.0의 거대하고 명시적인 복잡성과 Software 2.0의 통계적 예측 능력이 결국 수학적 확률 공간이라는 거대한 틀 안에서 상호 교차하며 융합되고 있음을 시사한다.

4. Software 2.0의 한계: 확률적 비결정성(Nondeterminism)과 엔지니어링 위기

Software 2.0 기반의 확률적 시스템은 데이터의 패턴을 학습하여 인간의 직관에 필적하는 인지적 문제 해결 능력을 제공하지만, 기존 시스템 아키텍처 및 품질 보증(QA) 체계와 극심한 마찰을 일으키는 본질적인 한계와 위협을 내포하고 있다.

4.1 ’침묵하는 실패(Silent Failure)’와 비직관적 동작

전통적인 소프트웨어는 예외 상황이 발생하면 명시적인 에러 메시지를 반환하거나 시스템을 종료(Crash)시킴으로써 문제를 드러낸다. 그러나 Software 2.0 스택은 완전히 비직관적이고 당혹스러운 방식으로 실패할 뿐만 아니라, 가장 치명적인 문제인 ’침묵하는 실패(Silently fail)’를 야기한다. 예를 들어, 수백만 개에 달하는 방대한 훈련 데이터 속에 편향성(Bias)이 내포되어 있을 경우, 시스템은 오류를 경고하지 않고 이 편향성을 조용히 학습하여 잘못된 결정을 확신에 차서 내리게 된다. 훈련 데이터의 덩치가 수백 기가바이트에서 테라바이트에 이르기 때문에 인간 개발자가 이를 전수 분석하고 디버깅하는 것은 불가능에 가깝다.

적대적 공격(Adversarial Attacks)의 존재 역시 신경망이라는 확률적 스택이 얼마나 비직관적으로 작동하는지를 뼈저리게 증명한다. 입력 데이터에 인간의 눈으로는 감지할 수 없는 미세한 픽셀 노이즈를 주입하는 것만으로도, 모델의 조건부 확률 분포가 완전히 요동치며 전혀 다른 객체로 오분류하게 만들 수 있다.

이러한 비결정성의 치명성은 자율주행과 같은 안전 필수(Safety-critical) 도메인에서 극명하게 대비된다. 구글의 웨이모(Waymo)가 택한 전통적인 접근 방식은 LIDAR와 레이더의 점군(Point cloud) 데이터를 사용해 지형과 장애물의 물리적 기하학(Geometry)을 프로파일링하여 이동 가능한 공간을 계산하는 방식이다. 이 구조에서는 객체를 인식하는 분류기(Classifier)가 물체를 “식별할 수 없음(Not identified)“으로 분류하더라도, 시스템은 물리적인 장애물이 존재한다는 사실 자체를 인지하고 보수적인 제어 판단(정지 등)을 내릴 수 있다. 예를 들어 “빗자루를 들고 칠면조를 쫓는 전동 휠체어 탄 여성“이라는 학습 데이터에 존재하지 않는 엣지 케이스(Edge case)가 나타났을 때, 분류기는 이를 실패로 처리하더라도 기하학적 시스템은 물리적 충돌을 피해 안전하게 차량을 정지시킨다.

반면 테슬라(Tesla)가 추구해 온 카메라 비전(Vision) 전용의 극단적인 Software 2.0 접근 방식은, 오직 신경망 이미지 분류기의 확률적 출력에 의존하여 제어 결정을 내린다. 이 경우 분류기가 확률적 오차나 적대적 노이즈로 인해 전방의 객체를 트레일러가 아닌 허공이나 도로의 표지판 등으로 잘못 인지하는 순간, 물리적 제어 매커니즘 전체가 무력화되어 대형 사고로 이어지는 치명적인 한계를 드러낸다. 데이터 세트가 커짐에 따라 노이즈가 상쇄될 것이라는 희망적 관측이 존재하지만, 롱테일(Long-tail) 분포에 위치한 희소한 상황에서는 분류기가 엉뚱한 이미지 디테일에 집착해 파국적인 결정을 내릴 수 있다.

4.2 패러다임 간의 구조적 비교와 품질 체계의 붕괴

기계 학습 컴포넌트가 기업의 핵심 소프트웨어 시스템으로 침투하면서 전통적인 품질 보증 생태계는 심각한 붕괴를 맞고 있다. 한 엔지니어의 고백처럼, 머신러닝 시대의 개발자들은 “퇴근할 때 내 코드가 완벽히 작동한다는 것을 100% 확신하고 집에 갈 수 있었던 시절“을 상실했다. 확률 모델, 지속적으로 업데이트되는 파라미터, 입력 데이터의 미세한 분산이 결합하여, 소프트웨어 공학이 지난 수십 년간 쌓아 올린 단위 테스트(Unit Testing), 정적 분석 등의 모범 사례들을 모조리 무용지물로 만들고 있는 것이다.

Software 1.0과 2.0 패러다임의 근본적인 구조적, 수학적 특성을 비교하면 이러한 품질 체계 붕괴의 원인이 명확히 드러난다. 아래의 비교 테이블은 두 패러다임의 차이를 요약한 것이다.

입력 시퀀스의 레이아웃 변화나 텍스트의 미세한 수정만으로도 토큰 예측 확률이 뒤바뀌어 결정 경계(Decision boundary) 근처의 출력이 전복될 수 있는 이 확률론적 기기(Stochastic instrument)를 안정적으로 운영하기 위해서는, 기존과는 완전히 다른 차원의 검증 메커니즘이 절실히 요구된다.

5. AI 소프트웨어 검증을 위한 오라클(Oracle)의 재정의와 확정적 정답지

Software 2.0 시스템의 가장 본질적인 엔지니어링 딜레마는, 주어진 입력에 대해 AI가 내놓은 결과물이 ’과연 올바른 것인가’를 판가름할 확고한 기준이 시스템 내부에 존재하지 않는다는 점이다. 소프트웨어 테스트 공학에서는 시스템 관찰 동작의 정합성을 구별해 내는 이 도전 과제를 **테스트 오라클 문제(Test Oracle Problem)**라 명명한다. 인간의 수동 개입 없이 병목 현상을 해결하기 위해 자동화된 오라클의 구축은 AI 테스트에서 가장 핵심적인 과제로 부상했다.

5.1 테스트 오라클과 결정론적 그라운드 트루스(Ground Truth)의 구조

오라클(Oracle)은 테스트 대상 시스템(System Under Test, SUT)의 특정 테스트 활동 시퀀스가 허용 가능한 동작인지 여부를 최종적으로 결정하는 술어(Predicate) 혹은 절차적 프로시저이다. 전통적인 명세 기반 오라클(Specified Oracles) 환경에서는 사전 및 사후 조건(Pre/Post-conditions)이나 계약(Contract)을 통해 정답을 수학적/논리적으로 모델링할 수 있었다.

형식적 정의에 따르면, 테스트 오라클 D는 테스트 활동 시퀀스 집합 TA를 불리언 참/거짓 집합 \mathbb{B}로 매핑하는 부분 함수(Partial function) D: TA \rightarrow \mathbb{B}로 표현된다. 그러나 얼굴 인식, 언어 이해, 주가 예측과 같이 복잡하고 방대한 도메인에서 동작하는 머신러닝 모델의 경우, 상상할 수 있는 모든 입력에 대해 완벽한 정답을 사전 정의하는 것은 불가능하다. 따라서 문헌에서는 모델의 출력이 지정된 범위 내에 존재할 확률적 타당성을 평가하는 확률적 테스트 오라클(Probabilistic Test Oracle) $\tilde{D}: TA \rightarrow $ 개념을 제안하기도 한다.

하지만 엔터프라이즈급 AI 시스템이나 결함이 치명적인 비즈니스 로직에 확률적 오라클을 단독으로 사용하는 것은 위험하다. 근본적인 신뢰성 확보를 위해서는 명확하고 절대적인 정답을 제공하는 결정론적 그라운드 트루스(Deterministic Ground Truth) 오라클 G에 의한 벤치마킹이 필수적이다. 그라운드 트루스 오라클 G는 언제나 ’절대적으로 올바른 답’만을 반환하는 전역 테스트 오라클(Total test oracle)이다. 이를 잣대로 삼아, 우리가 구축한 테스트 오라클 D의 신뢰성을 건전성(Soundness)과 완전성(Completeness)의 측면에서 엄밀하게 평가할 수 있다.

• 건전성 (Soundness): 테스트 오라클 D가 어떤 테스트 입력을 ’올바르다’고 평가했다면, 절대 정답지인 그라운드 트루스 G 역시 반드시 ’올바르다’고 평가해야 한다. 수식으로는 D(a) \Rightarrow G(a)가 성립해야 한다.
• 완전성 (Completeness): 절대 정답지 G가 ’올바르다’고 판별한 모든 정상적인 테스트 사례에 대해, 구축된 테스트 오라클 D도 빠짐없이 이를 ’올바르다’고 판별해 낼 수 있어야 한다. 수식으로는 G(a) \Rightarrow D(a)가 성립해야 한다.

결국 Software 2.0 테스트 공학의 목표는 확률적 시스템의 불확실성을 최소화하면서, 이 G에 최대한 근접하는 높은 건전성과 완전성을 지닌 D를 시스템 내부에 융합하는 데 있다.

5.2 메타모픽 테스팅과 딥러닝 화이트박스 검증 프레임워크

완벽한 그라운드 트루스 오라클을 확보하기 어려운 도메인의 한계를 극복하기 위해 제안된 도출형 오라클(Derived Oracles)의 대표적 기법이 **메타모픽 테스팅(Metamorphic Testing, MT)**이다. 이 혁신적인 접근법은 개별 입력에 대한 ’정확한 정답’을 요구하는 대신, 입력의 변환에 따라 시스템의 출력이 ’어떻게 논리적으로 변화해야 하는지’를 규정하는 메타모픽 관계(Metamorphic Relation)를 오라클로 활용한다. 예를 들어 자율주행 객체 인식 모델에서 원본 이미지의 명도를 일관되게 10% 높였을 때(입력 변환), 출력된 객체 식별 결과나 확률 값의 순위가 변경되지 않아야 한다는 불변성(Invariance) 규칙을 적용하는 것이다. 이 기법은 과학 계산용 소프트웨어를 위해 탄생했으나, 최근 머신러닝 알고리즘의 초기 테스트 실행 결과를 마이닝하여 관계를 점진적으로 개선하는 형태로 고도화되어 AI 오라클 문제의 훌륭한 해법으로 자리매김하고 있다.

이와 더불어 딥러닝 시스템의 내부 상태를 결정론적으로 검증하기 위해, 논문 DeepXplore: Automated Whitebox Testing of Deep Learning Systems에서 제시된 화이트박스 기반의 백투백(Back-to-Back) 테스팅 프레임워크가 널리 응용되고 있다. 기존 시스템 검증이 입출력만 확인하는 블랙박스 접근이었다면, DeepXplore는 신경망 내부의 활성화 뉴런 커버리지(Neuron Coverage)를 정량적 지표로 삼아 오라클 역할을 수행한다. 동일한 목적을 수행하는 복수의 차별화된 AI 모델(참조 모델)에 동일한 입력을 통과시킨 뒤 그 출력값을 상호 교차 비교(백투백 검증)함으로써, 단일 정답지가 없더라도 모델 간 출력 불일치가 발생하는 엣지 케이스를 결정론적으로 포착해 낼 수 있다.

6. 실전 예제: AI 시스템을 위한 결정론적 정답지 기반 오라클 구현

Software 2.0의 확률적 지능이 실제 기업의 CI/CD 파이프라인이나 운영 환경에 배포되기 위해서는, 대규모 언어 모델의 유연성과 전통적 시스템의 절대적 안정성을 결합하는 강력한 하이브리드 오라클 아키텍처가 구축되어야 한다. 단순히 자연어를 생성하는 챗봇을 넘어 SQL 쿼리를 작성하고, JSON 데이터를 파싱하며, 시스템 최적화 코드를 디버깅하는 AI 파이프라인에서는 철저한 결정론적 제어가 필수적이다.

6.1 Text-to-SQL 시스템의 실행 결과 비교 오라클 체계 구축

기업용 데이터베이스 벤더들은 앞다투어 AI의 자연어 처리 능력을 SQL로 매핑하는 기술을 도입하고 있다. 대표적으로 오라클 자율 운영 데이터베이스(Oracle Autonomous Database)는 Select AI 기능을 통해 Cohere 등의 대규모 언어 모델을 활용하여 사용자의 자연어 프롬프트 선언적 의도(Declarative intent)를 복잡한 SQL 문으로 실시간 번역한다.

문제는 “베이비붐 세대 중 상위 3명의 고액 소비자를 찾아라“와 같은 모호한 지시를 내렸을 때, LLM이 ’베이비붐 세대의 생년월일 기준’을 데이터베이스 스키마와 완벽하게 일치시켜 SQL을 확률적으로 올바르게 토큰 생성해 낼 것이라고 맹신할 수 없다는 것이다. 잘못된 SQL 생성은 치명적인 비즈니스 의사결정 오류로 직결된다. 이를 검증하고 회귀(Regression)를 방지하기 위해 필수적으로 도입되는 것이 바로 골든 데이터셋(Golden Dataset) 기반의 오라클이다.

전문 데이터 아키텍트가 구축하는 골든 데이터셋은 정상적인 쿼리, 엣지 케이스(경계 조건), 적대적 입력 시도, 대답 불가 질문 등 다양한 도메인 시나리오에 대해 인간 전문가가 엄밀하게 승인한 ‘그라운드 트루스’ SQL과 메타데이터를 포함한다.

이 환경에서 AI의 산출물을 검증하는 오라클 평가 파이프라인은 다음과 같이 실행 기반(Execution-based)의 결정론적 방식으로 구동된다.

1. 시스템은 AI 모델에 골든 데이터셋의 질문(“어제 목표 대비 실적은?”)을 입력하여 확률적 결과물인 후보 SQL 문장 x를 도출한다.
2. 일반적인 텍스트 생성 작업에서는 LLM-as-a-Judge 기법을 통해 평가용 AI가 산출된 문서를 검토하지만, SQL 평가에서는 단순 문자열 유사도나 F1 Score 비교가 무의미하다. 완전히 다른 형태의 SQL 쿼리라 할지라도 논리적으로 동일한 결과를 반환할 수 있기 때문이다.
3. 이에 따라 **실행 결과 비교 오라클(Execution-based Oracle)**이 가동된다. 자동화된 테스트 러너가 AI가 생성한 SQL과 골든 데이터셋의 정답 SQL을 완벽히 격리된 샌드박스 데이터베이스 환경에 동시 투입하여 실행한다.
4. 두 쿼리 실행 결과로 반환된 테이블의 행(Row count) 수, 열(Column) 데이터 값, 정렬 순서가 수학적 수준에서 100% 일치하는지를 결정론적인 알고리즘으로 비교 및 판별한다. 이 과정에서 영(0) 카운트의 처리나 숫자형 데이터의 소수점 미세 변동과 같은 엣지 케이스까지 사전에 정의된 규칙에 따라 엄격히 검증하여 건전성 오류를 원천 차단한다.

6.2 데이터 정합성 보장을 위한 JSON Schema 강제형 오라클

확률적 모델인 LLM이 생성한 응답 텍스트가 후속 API 파이프라인 호출의 페이로드로 직결되거나 구조화된 데이터 추출에 사용되는 환경에서는, 텍스트 형태가 정확한 스키마 구조를 따르는지 여부가 시스템 생존을 결정짓는다. Software 1.0에서는 강타입(Strong typing) 언어와 컴파일러가 이러한 구조적 무결성을 사전 보장하지만, Software 2.0 환경에서는 온도(Temperature) 하이퍼파라미터를 0으로 억제하거나 시스템 프롬프트에 형식적 지시를 가미하는 수준만으로는 100%의 데이터 정합성을 담보할 수 없다.

이러한 불확실성을 통제하기 위해, 파이프라인 설계자들은 JSON Schema Validation 메커니즘을 시스템의 결정론적 게이트웨이 오라클로 전면 배치한다. LLM이 추론 과정(Reasoning)을 거쳐 생성한 일련의 문자열 시퀀스가 유효한 JSON 포맷 문법을 준수하는지를 넘어서, 대상 API가 요구하는 필수 키(Key) 값의 누락 여부, 데이터 타입 일치 여부 등을 OpenAPI 스키마 규칙 등에 기대어 구문 분석 수준에서 철저하게 결정론적으로 검사하는 것이다.

특히 최신의 안정적인 파이프라인들은 모델의 디코딩 단계 자체를 통제하는 방식을 채택한다. 예를 들어 max_tokens=1로 설정하여 출력을 제한된 레이블 맵(Label map)에 강제로 매핑하거나, 타이핑(Typing)이 명시된 JSON 포맷 하에서 범위 체크(Range checks)를 수행하도록 제약 조건을 부여한다. 만일 오라클 검사에서 스키마 위반이 감지될 경우 즉시 실패 처리(Reject-on-fail)하고, 제한된 횟수 내에서 백오프(Bounded retries) 로직을 구동시켜 모델이 형식을 수정하여 재출력하도록 시스템을 강제한다. JQ-By-Example과 같은 도구의 아키텍처는 이를 훌륭히 구현하고 있다. LLM이 생성한 JQ 필터 코드를 실제 JQ 실행 파일과 입력 예제를 통해 실행하고, 그 산출물을 Jaccard 유사도나 스칼라 추출 방식을 통해 예상 출력값과 결정론적으로 대조한다. 만약 오류가 발생하면 구문(Syntax), 형태(Shape), 키 누락 등의 유형을 분류하여 명확한 논리적 피드백을 다시 LLM으로 주입해 출력을 정제시킨다.

6.3 운영 연구(OR) 솔버의 피드백을 활용한 반복적 디버깅 루프

가장 복잡한 수준의 하이브리드 오라클 체계는 고도의 전문성이 요구되는 운영 연구(Operations Research, OR)나 선형 계획법(Linear Programming) 코드 생성 분야에서 그 위력을 발휘한다. 기존의 LLM 평가 벤치마크들은 AI 모델에 문제 설명을 주고 단일 샷(One-shot)으로 코드를 생성하는 번역 능력 평가에 치중해 왔으나, 이는 실제 전문가들의 디버깅 과정을 철저히 외면한 방식이다.

복잡한 제약 조건을 가진 수리 최적화 모델에서는 생성된 코드가 단순히 컴파일되는 것을 넘어, 수학적으로 해(Solution)를 산출할 수 있어야 한다. 만약 최적화 솔버(Solver)가 ‘실행 불가능(Infeasible)’ 상태를 반환할 경우, 결정론적 수학 알고리즘 시스템은 동시에 충족될 수 없는 최소 제약 조건 집합인 **IIS(Irreducible Infeasible Subsystem)**를 추출하여 제공한다.

이 IIS는 일반적인 에러 메시지와 달리 문제의 본질을 수학적으로 입증하는 최소 단위의 ’불가능 증명서(Certificate of infeasibility)’이다. AI 기반 디버깅 파이프라인에서 이 수학적 최적화 솔버는 완벽한 결정론적 오라클의 역할을 수행한다. 솔버-인-더-루프(Solver-in-the-loop) 프레임워크 내에서 LLM 에이전트는 이 결정론적 피드백(IIS 증명서, 슬랙 값, 목적 함수 바운드 등)을 수신하고, 어떤 제약 조건이 논리적으로 모순을 일으켰는지 진단하여 코드를 체계적이고 구조적으로 자가 수정(Self-correction)한다. 이는 단순히 LLM에게 스스로 오류를 검토하라고 지시하는 약한 수준의 비결정적 피드백 루프를 뛰어넘어, 수리 논리적으로 반박 불가능한 결정론적 오라클의 검증 결과를 LLM의 추론 사슬에 주입함으로써 문제 해결 능력을 비약적으로 끌어올리는 Software 2.0 엔지니어링의 궁극적인 지향점을 보여준다.

이렇듯 AI 시스템 기반의 소프트웨어 개발 패러다임이 확산될수록, 개발자의 주된 임무는 역설적이게도 AI의 자율성과 예측 불가능성을 통제하기 위한 강력하고 견고한 결정론적 제어벽과 오라클을 아키텍처 전반에 세밀하게 직조해 넣는 ’오케스트레이션(Orchestration)’의 과정으로 귀결되고 있다. 데이터에 의해 지시되는 확률적 메타 소프트웨어의 파괴력은 오직 치밀하게 설계된 결정론적 정답지라는 수문을 통과할 때 비로소 진정한 비즈니스적 가치와 신뢰성을 획득하게 된다.

7. 참고 자료

1. The transition from Software 1.0 to Software 2.0 | Insights | Liontrust Asset Management PLC, https://www.liontrust.com/insights/blogs/2025/02/the-transition-from-software-1-to-software-2-short
2. Andrej Karpathy: Software Is Changing (Again) - The Singju Post, https://singjupost.com/andrej-karpathy-software-is-changing-again/
3. Building the Software 2 0 Stack (Andrej Karpathy) - YouTube, https://www.youtube.com/watch?v=y57wwucbXR8
4. Building the Software 2.0 Stack by Andrej Karpathy [video] - Hacker News, https://news.ycombinator.com/item?id=17280454
5. Software 2.0. I sometimes see people refer to neural… | by Andrej …, https://karpathy.medium.com/software-2-0-a64152b37c35
6. An Illustration of Software 2.0 - Cedric Warny - Medium, https://cwarny.medium.com/an-illustration-of-software-2-0-3937f620cea1
7. Software 2.0 and Data Programming: Lessons Learned, and What’s Next - Hazy Research, https://hazyresearch.stanford.edu/software2
8. Software 20 - Lark, https://www.larksuite.com/en_us/topics/ai-glossary/software-20
9. [N] Software 2.0 - Andrej Karpathy : r/MachineLearning - Reddit, https://www.reddit.com/r/MachineLearning/comments/7cdov2/n_software_20_andrej_karpathy/
10. Software 2.0: An Emerging Era of Automatic Code Generation - The Softtek Blog, https://blog.softtek.com/software-2.0-an-emerging-era-of-automatic-code-generation
11. Debugging Training Data for Software 2.0 | Stanford DAWN, https://dawnd9.sites.stanford.edu/news/debugging-training-data-software-20
12. The Case for Learned Index Structures - DSpace@MIT, https://dspace.mit.edu/bitstream/handle/1721.1/132272/3183713.3196909.pdf?sequence=2&isAllowed=y
13. (PDF) The Case for Learned Index Structures - ResearchGate, https://www.researchgate.net/publication/325376198_The_Case_for_Learned_Index_Structures
14. [1712.01208] The Case for Learned Index Structures - arXiv, https://arxiv.org/abs/1712.01208
15. The next 50 Years in Database Indexing or: The Case for Automatically Generated Index Structures - VLDB Endowment, https://www.vldb.org/pvldb/vol15/p527-dittrich.pdf
16. A Tutorial on Learned Multi-dimensional Indexes - CS@Purdue, https://www.cs.purdue.edu/homes/aref/LMDI2020/LMDI_Tutorial_SIGSpatial2020.pdf
17. 机器学习2025_2_10 - arXiv每日学术速递, http://arxivdaily.com/thread/64012
18. Probabilistic Software Modeling: A Data-driven Paradigm for Software Analysis - arXiv, https://arxiv.org/pdf/1912.07936
19. Variance-Aware LLM Annotation for Strategy Research: Sources, Diagnostics, and a Protocol for Reliable Measurement - arXiv, https://arxiv.org/html/2601.02370v3
20. 3 Elicitation - Machine Learning from Human Preferences, https://mlhp.stanford.edu/src/chap3.html
21. Overparameterization: A Connection Between Software 1.0 and Software 2.0 - DSpace@MIT, https://dspace.mit.edu/bitstream/handle/1721.1/130046/LIPIcs-SNAPL-2019-1.pdf?sequence=2&isAllowed=y
22. Software Engineering 2.0 - Neal Lathia, https://nlathia.github.io/2020/08/ML-Collaboration.html
23. AI vs Traditional Software Solutions: Key Differences & Benefits - Kovench, https://www.kovench.com/blog/ai-vs-traditional-software-solutions-making-the-strategic-choice-for-enterprise-success
24. Quality Model and Quality Characteristics Evaluation Suitable for Software 2.0 - Taiwan Association of Engineering and Technology Innovation, https://ojs.imeti.org/index.php/IJETI/article/view/13303/1549
25. The Oracle Problem in Software Testing: A Survey - EECS 481, https://eecs481.org/readings/testoracles.pdf
26. Testing AI Systems: Handling the Test Oracle Problem - DEV Community, https://dev.to/qa-leaders/testing-ai-systems-handling-the-test-oracle-problem-3038
27. The Oracle Problem in Software Testing: A Survey - IEEE Xplore, https://ieeexplore.ieee.org/iel7/32/7106034/06963470.pdf
28. What is Metamorphic Testing of AI? - testRigor AI-Based Automated Testing Tool, https://testrigor.com/blog/what-is-metamorphic-testing-of-ai/
29. (PDF) The Oracle Problem in Software Testing: A Survey - ResearchGate, https://www.researchgate.net/publication/276255185_The_Oracle_Problem_in_Software_Testing_A_Survey
30. A Machine Learning Approach for Developing Test Oracles for Testing Scientific Software - KSI Research, https://ksiresearch.org/seke/seke16paper/seke16paper_137.pdf
31. DeepXplore: automated whitebox testing of deep learning systems - ResearchGate, https://www.researchgate.net/publication/336782483_DeepXplore_automated_whitebox_testing_of_deep_learning_systems
32. [1705.06640] DeepXplore: Automated Whitebox Testing of Deep Learning Systems - arXiv, https://arxiv.org/abs/1705.06640
33. Test Selection for Deep Learning Systems - ORBilu, https://orbilu.uni.lu/bitstream/10993/44550/1/0-tosem%20%281%29.pdf
34. DeepXplore: Automated Whitebox Testing of Deep Learning Systems - Computer Science at Columbia University, https://www.cs.columbia.edu/~junfeng/papers/deepxplore-sosp17.pdf
35. DeepXplore: Automated Whitebox Testing of Deep Learning Systems - ResearchGate, https://www.researchgate.net/publication/320358768_DeepXplore_Automated_Whitebox_Testing_of_Deep_Learning_Systems
36. Nexus: Execution-Grounded Multi-Agent Test Oracle Synthesis - OpenReview, https://openreview.net/forum?id=lbZNHMqMAI
37. Agent-Driven GenAI Testing: From Golden Data to End-to-End Regression - Medium, https://medium.com/@mail.sainath.kumar/agent-driven-genai-testing-from-golden-data-to-end-to-end-regression-060408dbc17d
38. Generate SQL Queries with AI and Natural Language | Oracle, https://www.oracle.com/artificial-intelligence/generate-sql-queries-with-ai/
39. Introducing Select AI – Natural Language to SQL Generation on Autonomous Database, https://blogs.oracle.com/machinelearning/introducing-natural-language-to-sql-generation-on-autonomous-database
40. Golden Datasets: The Foundation of Reliable AI Evaluation | by fedemoreno613 - Medium, https://medium.com/@federicomoreno613/golden-datasets-the-foundation-of-reliable-ai-evaluation-486ce97ce89d
41. Build Advanced Retrieval-Augmented Generation Systems | Microsoft Learn, https://learn.microsoft.com/en-us/azure/developer/ai/advanced-retrieval-augmented-generation
42. Text To SQL: Evaluating SQL Generation with LLM as a Judge - Arize AI, https://arize.com/blog/text-to-sql-evaluating-sql-generation-with-llm-as-a-judge/
43. Oracle AI Database New Features, https://docs.oracle.com/en/database/oracle/oracle-database/26/nfcoa/all-nfg.html
44. Engineering a Retail Virtual Assistant in the Age of AI, https://www.dae.mn/blog/engineering-a-retail-virtual-assistant-in-the-age-of-ai
45. Validate JSON Using OpenAPI Schema in VS Code - Stack Overflow, https://stackoverflow.com/questions/74446382/validate-json-using-openapi-schema-in-vs-code
46. AI-powered jq filter synthesis from input/output JSON examples - GitHub, https://github.com/nulone/jq-by-example
47. Solver-in-the-Loop: MDP-Based Benchmarks for Self-Correction and Behavioral Rationality in Operations Research - arXiv, https://arxiv.org/html/2601.21008v2
48. Solver-in-the-Loop: MDP-Based Benchmarks for Self-Correction and Behavioral Rationality in Operations Research - arXiv, https://arxiv.org/html/2601.21008v1